home *** CD-ROM | disk | FTP | other *** search
/ Ian & Stuart's Australian Mac: Not for Sale / Another.not.for.sale (Australia).iso / fade into you / being there / Issues & Ideas / VMRL / survey_results < prev    next >
Text File  |  1994-10-01  |  13KB  |  295 lines
  1.  
  2.                           RESULTS OF THE VRML SURVEY
  3.                                        
  4.    Brian Behlendorf, brian@wired.com
  5.    Thu, 18 Aug 1994 22:15:58 -0700 (PDT)
  6.    
  7.    I collected the survey results together, threw out the submissions
  8.    which were apparently just tests (i.e., every option was "now" and no
  9.    proposals were voted on, this being the default setup). I arranged the
  10.    results in order of "now" ranking. (Refer to
  11.    http://www.wired.com/vrml/vrml-survey.html for what the survey
  12.    looked like).
  13.  
  14. Attribute:             now     later   never   no opinion
  15. ----------------------------------------------------------
  16. Caching of objects:    50      3       1       1
  17. Level of Detail:       48      5       1       2
  18. Geometric Primitives:  48      7       0       1
  19. Object-Oriented:       44      4       4       3
  20. Texture mapping:       44      11      0       1
  21. Standardized metrics:  40      3       6       7
  22. Engines:               40      13      0       3
  23. "Recommended" views:   39      9       5       3
  24. Matrix Representations:        39      11      1       1
  25. Hooks/API:             39      15      1       1
  26. Transparancy rendering:        39      15      0       2
  27. Obj desc./scene layout:        38      2       7       9
  28. Scripting language:    29      19      3       5
  29. Environmental Physics: 28      23      2       3
  30. Inlined Sound support: 25      27      1       3
  31. Typing Reps for links: 23      6       19      2
  32. Bezier Curves:         20      34      0       2
  33. NURBS support:         18      29      0       9
  34. Fractal Geometry:      14      35      6       1
  35. CORBA support:         8       8       1       39
  36. OLE:                   5       18      4       29
  37. Hytime support:                4       3       4       45
  38.  
  39.  
  40.    
  41.    
  42. Discussion:
  43.  
  44.    
  45.    
  46.    As has been pointed out after I put out the survey, we don't have to
  47.    worry about caching of objects - as long as we allow for URL's and
  48.    their sister URI's, we're fine, as there are other workgroups
  49.    dedicated to solving this very problem.
  50.    
  51.    A large number of people indicated that they weren't knowlegeable
  52.    enough about CORBA, OLE, and Hytime to decide whether or not they
  53.    should be included in any specification. I suppose we should deal with
  54.    this in the form of, let's try and leave a right-sized hole in the
  55.    code for what these technologies are supposed to provide. My guess is
  56.    that if these protocols are well designed, we don't have to worry
  57.    explicitely about incorporating them into the language. Hopefully
  58.    people knowlegeable about these can offer suggestions when we come up
  59.    with the spec as to what we're doing right or wrong.
  60.    
  61.    The most contested issue was "Typing Representations for links", which
  62.    I described as "should a VRML link be represented as a door, while an
  63.    image link could be represented as a painting, etc. User-definable." I
  64.    realize now that this was misleading - I wasn't suggesting that all
  65.    links to other vrml spaces be represented as doors, or images as
  66.    paintings, etc. Furthermore, this is almost exclusively a client issue
  67.    - how they want to represent links that aren't fully described it
  68.    totally up to them (just like the NCSA logo that appears when inlined
  69.    image loads fails). Thus, the question doesn't have much bearing on
  70.    the language.
  71.    
  72.    One last potential blunder was in asking about a two-tiered object
  73.    description/scene layout system, whereby we make a distinction between
  74.    files that simple describe arbitrary documents, and files that
  75.    describe entire scenes (lighting, etc.). However, I now realize that
  76.    this is also a browser issue; what I was trying to avoid were
  77.    situations where one scene #includes another scene, and their lighting
  78.    and camera layout descriptions might collide. If we accept that
  79.    there's no minimal required elements for a VRML file, and that
  80.    duplicate elements like lighting can be handled by the browser, then
  81.    including one file in another file is fine.
  82.    
  83.    That leaves:
  84.  
  85. Level of Detail:       48      5       1       2
  86. Geometric Primitives:  48      7       0       1
  87. Object-Oriented:       44      4       4       3
  88. Texture mapping:       44      11      0       1
  89. Standardized metrics:  40      3       6       7
  90. Engines:               40      13      0       3
  91. "Recommended" views:   39      9       5       3
  92. Matrix Representations:        39      11      1       1
  93. Hooks/API:             39      15      1       1
  94. Transparancy rendering:        39      15      0       2
  95. Scripting language:    29      19      3       5
  96. Environmental Physics: 28      23      2       3
  97. Inlined Sound support: 25      27      1       3
  98. Bezier Curves:         20      34      0       2
  99. NURBS support:         18      29      0       9
  100. Fractal Geometry:      14      35      6       1
  101.  
  102.  
  103.    
  104.    
  105.    There appears to be a good break in between the transparency rendering
  106.    support and the full scripting language. In previous conversations on
  107.    the list, we had sort of agreed that language construction is a very
  108.    thorny problem, a very big wheel to reinvent. The concensus seemed to
  109.    be to leave it to the next rev of the VRML spec, or simply leave a
  110.    hole big enough for any arbitrary scripting language to take its
  111.    place. (I.e., Perl, TCL, Lisp, etc.) I personally prefer the latter.
  112.    
  113.    So anyways, it looks like we have our requirements for the baseline
  114.    spec for VRML 0.1 (to become 1.0 when we hash it out and have working
  115.    clients). The survey form stated (without objection) that we can take
  116.    these requirements as basic:
  117.  
  118.         Platform independence
  119.         True 3-d information (not pre-rendered texture maps a la DOOM)
  120.         PHIGS-ish lighting and view model
  121.         Unrecognized data types are ignored (to leave open future development)
  122.         Hierarchical data structure
  123.         Lightweight Design
  124.         Convex and Concave objects allowed
  125.         Fill-in-the-details support (pictures in a museum)
  126.         The file format is public domain
  127.  
  128.    to which we add:
  129.    
  130.    Level of Detail support
  131.           Allow authors to specify what level of detail corresponds to
  132.           their object representations.
  133.           
  134.    Geometric Primitives
  135.           Having a set of standard definitions for things like spheres,
  136.           cones, cylinders, etc, so that they don't need to be defined
  137.           with hundreds of polygons.
  138.           
  139.    Object-Oriented
  140.           Being able to define classes and instances of objects.
  141.           
  142.    Texture mapping
  143.           Map bitmaps onto specified geometries.
  144.           
  145.    Standardized metrics
  146.           Enforcing some standard for real-world measurement, when
  147.           desired. I.e., basing things on meters - basically an object
  148.           defined as a 5x5x5 cube from one file has no problem fitting
  149.           inside a 6x6x6 cube in another file.
  150.           
  151.    Engines
  152.           Simple well-defined engines to base variables on, like "time"
  153.           or "door opening" or linking to an event.
  154.           
  155.    "Recommended" views
  156.           Ability to define camera positions and angles for people
  157.           entering the scene.
  158.           
  159.    Matrix Representations
  160.           Allow 4x4 matrices to represent object transformations.
  161.           Standard "rotate" and "translate" commands should be supported
  162.           too.
  163.           
  164.    Hooks/API
  165.           Provide the ability to "export" variables for control by
  166.           outside programs.
  167.           
  168.    Transparancy rendering
  169.           Have one attribute of surfaces be transparancy.
  170.           
  171.    
  172.    
  173.    What can wait until later is:
  174.    
  175.    Full scripting language
  176.           Again, we might not need this.
  177.           
  178.    Environmental Physics
  179.           Specifying scene-specific characteristics like gravity, ambient
  180.           temperature, etc. This would define a small set of these
  181.           characteristics that would be common to all objects in a scene.
  182.           
  183.    Inlined Sound support
  184.           I.e., the radio gets louder as you walk towards it. This was
  185.           probably shelved just as a complexity issue.
  186.           
  187.    Bezier Curves, NURBS support and Fractal Geometry
  188.           These are advanced modeling and rendering techniques we should
  189.           see (or at least allow for) in VRML, but also require more
  190.           complex rendering algorithms.
  191.           
  192.    
  193.    
  194. Proposal Popularity
  195.  
  196.    
  197.    
  198.    Before I go into the politically touchy subject of proposal
  199.    comparison, I should state that when you have 8 proposals that you
  200.    have to narrow down to a few, and then to one on which to base the
  201.    language, you're going to end up stepping on toes and getting on
  202.    people's bad side. What I hope language proposal authors realize is
  203.    that, at the root of things, these languages describe basically the
  204.    same thing, a 3-d space. Not having your specific proposal selected
  205.    doesn't exclude you from working with VRML; in fact, what I'm hoping
  206.    is that the standardized version of VRML we select is something for
  207.    which translators from the various other languages can be written,
  208.    perhaps written easily. To my eye, the construct (at some points even
  209.    grammar) of several of the languages seems isomorphic. The whole point
  210.    of a common format is to stop the reinventing of a language every time
  211.    someone wants to describe *space*. In this spirit, I ask that we all
  212.    have a little understanding of this issue and continue to work
  213.    together even after the chips are down - because it's after the
  214.    language is resolved that the real fun (writing clients) begins. :)
  215.    
  216.    At the end of the survey you were asked to give 4 votes on which
  217.    browsers you thought had the most potential. I removed duplicate votes
  218.    (cases where someone voted for a proposal 4 times counted only as 1
  219.    vote) and got these results:
  220.  
  221. Inventor:      26
  222. OOGL:          20
  223. Labyrinth:     15
  224. CDF:           14
  225. Manchester:    12
  226. FFIVW:         8
  227. Meme:          4
  228. TSIPP:         1
  229.  
  230.  
  231.    
  232.    
  233.    It seems safe to say from this that we can narrow out FFIVW, Meme, and
  234.    TSIPP. Meme is more expansive than just a language, it specifies a
  235.    communications stream as well, so there might be something from Meme
  236.    we can still use later. "File Format for the Interchange of Virtual
  237.    Worlds" is good, but it seemed very similar to Manchester Scene
  238.    Description Language already. TSIPP I unfortunately never got to
  239.    experiment with so I can't explain its showing. Additionally, Mark
  240.    Pesce and the Labyrinth group has claimed that they have no love for
  241.    their language - it was only something they came up with in a few
  242.    hours to do the job they needed done. Finally, I've looked over the
  243.    Machester Scene Description Language spec and it seems very similar to
  244.    CDF; similar enough that I think they could be judged on the same
  245.    grounds. Which leaves:
  246.  
  247. Inventor:      26
  248. OOGL:          20
  249. CDF:           14
  250.  
  251.  
  252.    
  253.    
  254.    I'd like to at this point declare these 3 as the remaining valid
  255.    candidates for basing the VRML spec upon. What I think should happen
  256.    now is this: the people responsible for these proposals (or others who
  257.    use these languages) should come up with a short declaration of what
  258.    subset of their language (or what additions to their language) would
  259.    define VRML 0.1. Ideally they'd put this up on the web and open it to
  260.    review (some space on the vrml home pages can definitely be provided
  261.    for this). Working clients available for downloading and testing that
  262.    implement the spec with the language would be even better, or perhaps
  263.    a WWW interface to a virtual browser (though it's the feel of the
  264.    language and their capacities that are the important part). Members of
  265.    the list can debate the proposals for a couple of weeks, and then
  266.    we'll have another vote. Since the fleshing out of the language will
  267.    occur when the teams have submitted their final spec-conforming
  268.    proposal, we will then have our standard spec-conforming language, and
  269.    can begin work on writing clients and modifying the parsers on
  270.    existing clients.
  271.    
  272.    The OOGL supporters already has a lead in making their proposal
  273.    available on the WWW, though the Inventor crew has laid out some ways
  274.    for Iv. to conform to a minimalist spec (though they might want to
  275.    revise it now). The CDF crew have a couple documents on the web server
  276.    here describing their language. We on the outside can spend out time
  277.    going over these proposals with a fine-toothed comb, declaring what we
  278.    like or don't like about each of them, debating their features, etc. I
  279.    expect this part to be busy, but hopefully we can remain flame-free.
  280.    
  281.    Let's get to work :)
  282.    
  283.    Finally, I suggest changing the "M" in "VRML" from "Markup" to
  284.    "Modeling". It was originally termed VRML to signify its conceptual
  285.    relationship to HTML - but we now see it's much more a modeling
  286.    language than a markup language. Unless I get a storm of protest, I'll
  287.    implement this change.
  288.    
  289.    My analysis of the survey results is open to comment, but I feel
  290.    fairly confident in it, and revising it isn't something I'll do
  291.    lightly, as it's mostly based on the expressed opinion of the group
  292.    anyways. Commentary is fine - it's what makes us a community. :)
  293.    
  294.    Brian
  295.